perm filename MESSAG.TXT[PAT,LMM] blob
sn#097624 filedate 1974-04-15 generic text, type T, neo UTF8
7-APR-74 14:30:09,1039
Net mail from site BBN-TENEX rcvd at 7-APR-74 14:30:06
-------
Date: 7-APR-74 1732-EDT
From: LEWIS at BBN-TENEX
cc: TEITELMAN at PARC-MAXC
- - - -
THE NEW RECORDSTRUC HAS BEEN FTPED TO BBN.
RE: SPRINT AND STRUCP
BOTH WERE ORIGINALLY WRITTEN TO HELP ME DEBUG THE STRUCTURE
PACKAGE. I LEFT THEM IN THINKING THAT OTHER PEOPLE WOULD LIKE THEM.
SPRINT IS NO REAL HELP TO ANYONE SINCE DATATYPES SO VERY OFTEN
ARE USED WITH DOUBLE LINKED LISTS AND THE LIKE. I REALLY
HAVE TO START GIVING SOME THOUGHT TO A GENERALIZED PRINT.
STRUCP SEEMED NICE TO ME, BUT NO ONE EVER USED IT.
IN FACT, EVERYONE THAT I KNEW OF HERE THAT WAS USING
STRUC, HAS NOW SWITCHED TO RECORDS AND ARE
MUCH HAPPIER WITH THE CHANGE. I HAVE HAD NO COMPLAINTS
ABOUT SPRINT OR STRUCP MISSING.
RE: RECORDSTRUC.DOC
I JUST LOOKED AT IT AND DON'T THINK THAT COMPILETYPELST
SHOULD BE DOCUMENTED AT THIS TIME. I PLAN TO CHANGE IT AT
SOME TIME IN THE FUTURE. EVEN DEFEVAL WILL CHANGE, BUT
IT WILL BE COMPATIBLE WITH THE CURRENT VERSION.
DARYLE
-------
7-APR-74 18:50:22,464
Date: 7 APR 1974 1850-PDT
From: TEITELMAN
- - - -
It has always been the case thatif you are recompiling
any of the functions in a block, the entire block
is recompiled. The option FNS/VARS given
to LOADFNS (or LOADVARS) will load fileFNS fileVARS
and fileBLOCKS. I plan to make it esy
for you to request loading all of the functins
in a given block by giving one of the function
names. However, if you delete the block declarations
t.s.
-------
7-APR-74 19:02:21,1043
Net mail from site BBN-TENEX rcvd at 7-APR-74 19:02:18
Date: 7 APR 1974 2204-EDT
From: LEWIS at BBN-TENEX
Subject: DEFEVAL AND COMPILETYPELST
- - - -
I SOMETIMES USE DEFEVAL.
TO KEEP IT CLEAN I SAY SOMETHING LIKE
(DEFEVAL (NTYP (CREATE FOO)) FUNCTION).
I EVENTUALLY PLAN TO MAKE DEFEVAL TAKE A TYPE NAME, I
SHOULD REALLY HAVE THE SUBR BE DEFEVAL1 AND DEFEVAL WOULD THEN
BE WRITTEN IN LISP. ILL DO THAT ON THE NEXT ASSEMBLY.
I HAVE NEVER HAD A USE FOR COMPILETYPELST AND DONT KNOW
ANYONE WHO HAS. I JUST STUCK IT IN TO PRESERVE SOME
COMPATIBILITY WITH THE COMPILER. UNTIL I HAVE
SOME WAY TO READ AND PRINT DATA-TYPES, I CANT SEE HOW IT
COULD BE USED.
I LOOK ABOVE, GUESS I SHOULD ADD THAT
THE CHANGE WITH DEFEVAL WOULD ALLOW IT TO TAKE A TYPE NAME.
MUCH OF THE PROBLEM HERE BOILS DOWN TO READING AND PRINTING
DATA-TYPES, SOMETHING I WILL REALLY GET ONTO ONCE READTABLES AND SUCH
ARE REALLY CHECKED OUT. THE READING WILL OBVIOUSLY BE SOLVED BY
READMACROS, NOW WE NEED A USER-PROGRAMMABLE PRINT.
DARYLE
-------
7-APR-74 19:13:55,142
Date: 7-APR-74 1913
From: PRINTER
- - - -
File EXPAND.;3 sent to XGP
File LOADUP.;4 sent to XGP
File STRUCTURE.;3 sent to XGP
-------
8-APR-74 00:42:48,228
Net mail from site BBN-TENEX rcvd at 8-APR-74 00:42:47
-------
Date: 8-APR-74 0342-EDT
From: LEWIS at BBN-TENEX
Re: RECORDSTRUC
cc: TEITELMAN at PARC-MAXC
- - - -
NEW VERSION COPIED TO <LISP>@BBN.
DARYLE
-------
8-APR-74 03:06:16,282
Net mail from site BBN-TENEX rcvd at 8-APR-74 03:06:13
-------
Date: 8-APR-74 0605-EDT
From: LEWIS at BBN-TENEX
Re: DATADICT
- - - -
ARE YOU SURE THE PRETTYMACRO WORKS?
THE (QUOTE Y) EXPRESSION SHOULD MAKE ALL THE VARIABLE NAMES BE
Y. (SHOULDN'T IT?)
DARYLE
-------
8-APR-74 03:09:55,202
Net mail from site BBN-TENEX rcvd at 8-APR-74 03:09:53
-------
Date: 8-APR-74 0609-EDT
From: LEWIS at BBN-TENEX
Re: MORE
- - - -
WHY IS @2 CALLED WITH 2 ARGS WHEN IT ONLY TAKES ONE?
-------
8-APR-74 12:31:58,458
Date: 8 APR 1974 1231-PDT
From: TAFT
Subject: glitch?
- - - -
I have not heard of your problem; however, it may be another
symptom of the "teco twitch". The old "random zeroes" problem
(which occurred during pack-to-pack copying) was fixed about 2 months
ago. Detected memory errors will cause the affected process
to get an I/O data error interrupt. No idea what Lisp does with
those, but I assume it will type out something.
Ed
-------
8-APR-74 13:08:58,290
Net mail from site BBN-TENEX rcvd at 8-APR-74 13:08:55
-------
Date: 8-APR-74 1609-EDT
From: LEWIS at BBN-TENEX
Re: U.D.F
- - - -
THE "STRANGE" FUNCTION IS THE TYPE 8 FREE LISTS, IVE SEEN
IT BEFORE. DONT KNOW WHAT WOULD CAUSE IT. IF YOU FIND OUT, LET ME
KNOW.
DARYLE
-------
8-APR-74 18:30:10,145
Date: 8 APR 1974 1830-PDT
From: TEITELMAN
- - - -
will look at your clisp problems.
re radix, thats gilding the lily.
WARREN
-------
8-APR-74 20:28:40,302
Date: 8 APR 1974 2028-PDT
From: BENTLEY
Subject: 206 Assignment
- - - -
Sorry to clutter up your directory, Larry, but I have a couple
of mean TAs in a course I'm taking at school (I go to that Catholic
school, St. Anford's) who said I have to send a message to
someone.
Jon
-------
9-APR-74 04:46:08,315
Date: 9 APR 1974 0446-PDT
From: TEITELMAN
- - - -
Re your problems witt RECORD and CHANGEDRECLST.
I am planning on overhauling file package in next
day or so. I was aware that the interface
between LOADFNS and file package was not smooth.
I will keep your particular scenario in mind.
warren
-------
9-APR-74 14:29:31,696
Net mail from site BBN-TENEX rcvd at 9-APR-74 14:29:28
-------
Date: 9-APR-74 1716-EDT
From: LEWIS at BBN-TENEX
- - - -
LARRY,
DID YOU EVER FIND OUT WHAT WAS CAUSEING YOU TO
GET THAT HANDLE ON THE FREE LIST IN FUNCTION DEFS?
THE REASON I ASK IS THAT I HAVE A PROBLEM HERE
WHERE STRING POINTERS ARE GETTING CLOBBERED AT VERY VERY
FUNNY TIMES. I AM STARTING TO SUSPECT A GARBAGE COLLECT
PROBLEM WITH USER DATA-TYPES.
DID YOU HAVE ANY TYPES DEFINED WHEN YOU GOT YOU PROBLEM
AND IF SO, WERE THERE INSTANCES OF THE TYPE ABOURND?
IE, HAD YOU DONE SOME CREATES.
ALSO, HAD ANY GC'S OCCURED JUST BEFORE THE PROBLEM RAISED
ITS UGLY HEAD? (ANY GC'S, TYPE NOT IMPORTANT).
DARYLE
-------
9-APR-74 15:17:35,252
Date: 9 APR 1974 1517-PDT
From: JACKSON
- - - -
Larry,
Please let me know as soon as you have a new match.
I'd like to bring up a new innrscope in the next few days,
if possible without programming around the bug in match.
Phil
-------
9-APR-74 19:18:02,638
Net mail from site BBN-TENEX rcvd at 9-APR-74 19:18:00
-------
Date: 9-APR-74 2217-EDT
From: LEWIS at BBN-TENEX
Re: GC ERROR
- - - -
IT SHOULDNT BE RELATED TO ANY IO DATA ERROR, WHAT EVER THAT IS.
IVE PRETTY WELL VERIFIED THAT IT IS A GC PROBLEM.
AFTER THE CRUTIAL GC THE STRINGS ARE , NOW GET THIS, ACTUALLY
POINTERS INTO THE STRING POINTER FREE LIST.
SINCE YOU HAD A SIMILAR PROBLEM WHEN USING DATATYPES, I WILL
ASSUME THEY ARE GUILTY UNTILL PROVEN INSOCENT. THANX
DARYLE
P.S. DONT TRY TO GENERATE A TYPESCRIPT FOR ME, I HAVE
A CASE NOW WHICH IS PRETTY WELL NAROWWED DOWN TO THE
POINT IN TIME THAT I NEED.
-------
9-APR-74 20:57:18,348
Net mail from site BBN-TENEX rcvd at 9-APR-74 20:57:16
-------
Date: 9-APR-74 2356-EDT
From: LEWIS at BBN-TENEX
cc: BELL
- - - -
I HAVE FOUND THE GARBAGE COLLECT BUG WITH USER DATATYPES.
IT HAS BEEN FIXED AND WILL BE IN THE NEXT LOADUP.
I WANT TO THANK YOU BOTH FOR YOUR INPUTS WHICH HELPED ME TRACK
THIS THING DOWN.
DARYLE
-------
10-APR-74 18:39:37,546
Net mail from site SU-AI rcvd at 10-APR-74 18:37:20
-------
Date: 10-APR-74 1837 PST
From: MWK at SU-AI
- - - -
WELLL, ITS DONE.
"I AM PRESENTLY LOOKING AROUND FOR
SUMMER JOBS. [WITH A POSSIBILITY OF
EXTENSION INTO THE SCHOOL YR IF NECC.
DO YOU KNOW OF ANY IN C.S.L.? WOULD
YOU HAVE SUCH A POSITION? IF YOU KNOW
OF ANY, PLEASE LET ME KNOW @ MWK@SAIL.
CORDELL GREEN CAN PROVIDE A REFERENCE
IF NECC., AS WELL AS NORM HARDY
[TYMSHARE].
THANKS FOR UR TIME PETER,
SINCERELY,
MARK KAHRS.
"
GOT IT?
MARK.
-------
13-APR-74 00:35:59,241
Date: 13 APR 1974 0035-PDT
From: TEITELMAN
- - - -
Yes
I will use it. but i dont think I will release it because
there are other differences as well - i.e. statistics
dont get straightened out, i.e. cpu time etc.
warren
-------
13-APR-74 00:37:04,271
Date: 13 APR 1974 0037-PDT
From: TEITELMAN
- - - -
Wait a sec - cant you use it for other than
<SUBSYS>LISP.SAV? i.e. cant I tell it
to use LISPY.SAV or some such.
How about if I do a GET first or some such?
that would be more useful for me.
warren
-------
13-APR-74 02:22:13,238
Date: 13 APR 1974 0222-PDT
From: TEITELMAN
- - - -
documentaton
Plese send a
message to MANUAL about RECORDSTRUC documentaton, and
also in future send messages about documentaton to
manual as well as to me.
warren
-------
13-APR-74 02:25:04,283
Net mail from site BBN-TENEX rcvd at 13-APR-74 02:25:03
-------
Date: 13-APR-74 0524-EDT
From: LEWIS at BBN-TENEX
Re: records
cc: TEITELMAN at PARC-MAXC
- - - -
does the restriction on undoablity apply only to
user-data types or all REPLACE operations?
daryle
-------
13-APR-74 02:36:01,3775
Date: 13 APR 1974 0236-PDT
From: TEITELMAN
Subject: NEW LOADFNS
cc: DEUTSCH, MOORE, BOBROW, LEWIS at BBN, GOODWIN at BBN,
cc: BURTON at BBN
- - - -
New LOADFNS:
LOADFNS takes four arguments, FN, FILE, FLG, VARS.
First three as before. VARS can be T meaning
load all non-defineq's, VARS meaning load
all RPAQQ, or RPAQQ expressions, or
a list (a non-NIL atm is listed as with functions)
which mean load corresponding expressions.
The list is a list of atms which are
compared with CAR of form and CADR of form,
e.g. you can say LOADFNS(NIL FILE NIL (DEFLIST FOOFNS))
which will get the (RPAQQ FOOFNS -)
expression as well as all DEFLIST's.
VARS can also be FNS/VARS which is equivalent
tto FILEFNS FILEVARS FILEBLOCKS, e.g.
LOADFNS(NIL EDIT.COM NIL FNS/VARS).
If both FN and VAR are NIL, VAR defaults to T,
e.g. LOADFNS(NIL FILE) same as LOADFNS(NIL FILE NIL T).
IN addition, there is a LOADVARS function which
simply calls LOADFNS.
This LOADFNS builds a map of the functions, compiled
Now for the new part:
when BUILDMAPFLG is T, LOADFNS builds a map of
the function definitions in the file. LOADFNS
still stops when it is being aked to get some functions
and it finds them midway through the file. IN this case
there is a partial map, which can be used, or extended
if LOADFNS is asked to find other functions in the file
that it has not already scanned. The map is used
(regardless of BUILDMAPFLG) both for looking up
function definitions, and for avoiding SKREAD's, i.e.
to skip over defineq's and to
avoid having to call LCSKIP. LOADFNS builds the map
even when it is not looking for functions, e.g. when
you do LOADVARS(FNS/VARS FILE) you also get the
map built, on the grunds that it is just as fast
to do many SKREAD's as one big SKREAD so might as well
save locations.
Here are some timings:
LOADFNS(ZAP CLISPIFY) (i.e. scans entire file doesnt find anything)
116 CONSES 33 seconds with BUILDMAPFLG on
20 CONSES 33 seconds with flag off
subsequent
LOADFNS(ZIP CLISPIFY) now takes .17 seconds (thats right, .17 seconds
to return (NOT FOUND).
LOADFNS(CLDISABLE CLISPIFY)
(last function in CLISPIFY)
176 CONSES (for the function defiition)
.935 seconds
etc.
It is my plan to make LOAD also build the map by having
it do an RATOM and see the defineq and then read them in
one by one (when the BUILDMAPFLG is T).
It is also my plan to make PRETTYDEF use the map
if there when doing a remake option, and also
to have it update the map. (The map saves the full file
name so as to avoid confusion between version numbers).
I also inteend to bring
up the system with BUILDMAPFLG and MAKEFILEREMAKEFLG both
defaulted to T, and alice can change them if she wants.
I have not done the changes to PRETTYDEF or to LOAD, nor
have i done some fixes to file packge so a
to interface LOADFNS correctly, and also handle the
problem of compiled and interpeted files a little better.
These should not be too difficult. The hard paatt
was the LOADFNS. I also plan to provide a LOADBLOCKS which
will load an entire block given any of its functions, and
to have the editor ask you if you want that where it
now asks you if you want the function loaded.
I would appreciate if you would get on the new loadup
LISPZ.SAV on NEWLISPat PARC< LISP.SAV on TEITELMAN at BBN,
and bang hell out of it. There are an incredible number
of different situation involving the scan stopping
in the middle of a defineq, after a compiled function,
coming back in asking for some VARS when you have
previously scanned all or some of the file, etc. etc.
I have exhaustively tested these as well as I can, but
would appreciate some hostile users.
-------
13-APR-74 14:03:45,1255
Date: 13 APR 1974 1403-PDT
From: TEITELMAN
- - - -
Yes, this loadup is the very latest from BBN.
Re HELPFIX - will put thatin my basket for now.
Re MERGE, SYSIN and BARD, that
sounds ike a good suggestion. Incidentaaly, the
culprit is not entirely GREET but the fact that
when you start up LISP a lot of pages get made
private and copied things onto them etc. etc.
The disadvantage to your scheme is that BARD is
not a MAKESYS in this case, so (AA) cant set herald
and (B) cant have fast GC's.
So let us view BARDas being LISP insead.
Now if you adopt some kind of shceme similar to yours -
but pretend that there isnt a SYSOUT file, i.e.
just do a GET, and then jump in - where does
that leave us? What does not get done?
If you would like to do me a favor, how abut
poking around in HIST and see exactly where the
time IS going. Then we can see what
would be gained by cutting vrious things out.
I actually have this on my list of things to do,
but it sounds like you might be able to do it better,
and come up with a speeded up version for BARD,
although maybe not quite as simple or speedy
as you currently have for LISP, because having
some form of user initialization is important
for BARD.
warren
-------
13-APR-74 18:58:25,1572
Date: 13 APR 1974 1858-PDT
From: TAFT
Subject: control-C and buffer clearing
- - - -
1) First of all, nobody ever claimed that control-C would ever
behave exactly the same on Tenex as on 10/50. Having grovelled
through the innards of a 10/50 monitor, I can tell you that the
10/50 handling is not as simple as perhaps it looks from the outside,
e.g. there are a lot of special cases arising from entering and
leaving monitor command mode, what the break character set is, etc.
2) I wasn't sure from your note whether you were referring to
input buffering, output buffering, or both. When a deferred
interrupt is made immediate by typing two of them, the input buffer
is cleared automatically by Tenex, so I don't think that is
a problem. Automatically clearing the output buffer would, I think,
be incorrect in general, since primary input and output need not
be to the same device. Also, it might be true that the user wants
to see precisely how far his computation got before it
was stopped.
3) When the Exec receives a deferred terminal interrupt,
it does not know whether it occurred because of reading a single
control-C from the input stream or because of a double control-C
acting immediately. Clearing the output buffer in the former
case would clearly be bad. However, if the EXEC sees two control-C's
(caused by your typing three of them! to generate two immediate
interrupts), it does clear the output buffer.
An easier rule of thumb is simply to keep typing control-C until
output stops and you see "@".
Ed
-------
13-APR-74 21:42:06,356
Date: 13 APR 1974 2142-PDT
From: TAFT
Subject: input buffer clearing
- - - -
You are right, the (documented) input buffer clearing by double
deferred control-C was not working because the code was never put
in to do it. It has been fixed in 1.32, so I just lifted the
code from BBN and have patched it in. How's that for service?
Ed
-------
14-APR-74 01:16:04,302
Date: 14 APR 1974 0116-PDT
From: TEITELMAN
- - - -
I did the following experiment,
I timed start up time for LIP with and
without file USERNAMEFILE around. i.e. deleted it temporarily
difference was 5.9 seconds to 4.5 seconds so doesnt
seem like greeting costs too much.
warren
-------
14-APR-74 01:39:41,153
Date: 14 APR 1974 0139-PDT
From: TEITELMAN
- - - -
MAKEFILE(FILE NEW)
FOR ABORTING - USE CONTROL-E. ALL SHOULD BE WELL THEN.
WARREN
-------
14-APR-74 01:54:35,210
Date: 14 APR 1974 0154-PDT
From: TEITELMAN
- - - -
It does have the same meaning. YOu hve the wrong argument.
the fourth argument is vars, the third is ldflg.
use LOADVARS if you get confused.
-------
14-APR-74 03:30:56,6998
Date: 14 APR 1974 0330-PDT
From: TEITELMAN
- - - -
I'm not sure if you got the first message on this
subject matter, so am including the whole thing.
the latter part is new.
New LOADFNS:
LOADFNS takes four arguments, FN, FILE, FLG, VARS.
First three as before. VARS can be T meaning
load all non-defineq's, VARS meaning load
all RPAQQ, or RPAQQ expressions, or
a list (a non-NIL atm is listed as with functions)
which mean load corresponding expressions.
The list is a list of atms which are
compared with CAR of form and CADR of form,
e.g. you can say LOADFNS(NIL FILE NIL (DEFLIST FOOFNS))
which will get the (RPAQQ FOOFNS -)
expression as well as all DEFLIST's.
VARS can also be FNS/VARS which is equivalent
tto FILEFNS FILEVARS FILEBLOCKS, e.g.
LOADFNS(NIL EDIT.COM NIL FNS/VARS).
If both FN and VAR are NIL, VAR defaults to T,
e.g. LOADFNS(NIL FILE) same as LOADFNS(NIL FILE NIL T).
IN addition, there is a LOADVARS function which
simply calls LOADFNS.
This LOADFNS builds a map of the functions, compiled
Now for the new part:
when BUILDMAPFLG is T, LOADFNS builds a map of
the function definitions in the file. LOADFNS
still stops when it is being aked to get some functions
and it finds them midway through the file. IN this case
there is a partial map, which can be used, or extended
if LOADFNS is asked to find other functions in the file
that it has not already scanned. The map is used
(regardless of BUILDMAPFLG) both for looking up
function definitions, and for avoiding SKREAD's, i.e.
to skip over defineq's and to
avoid having to call LCSKIP. LOADFNS builds the map
even when it is not looking for functions, e.g. when
you do LOADVARS(FNS/VARS FILE) you also get the
map built, on the grunds that it is just as fast
to do many SKREAD's as one big SKREAD so might as well
save locations.
Here are some timings:
LOADFNS(ZAP CLISPIFY) (i.e. scans entire file doesnt find anything)
116 CONSES 33 seconds with BUILDMAPFLG on
20 CONSES 33 seconds with flag off
subsequent
LOADFNS(ZIP CLISPIFY) now takes .17 seconds (thats right, .17 seconds
to return (NOT FOUND).
LOADFNS(CLDISABLE CLISPIFY)
(last function in CLISPIFY)
176 CONSES (for the function defiition)
.935 seconds
etc.
It is my plan to make LOAD also build the map by having
it do an RATOM and see the defineq and then read them in
one by one (when the BUILDMAPFLG is T).
It is also my plan to make PRETTYDEF use the map
if there when doing a remake option, and also
to have it update the map. (The map saves the full file
name so as to avoid confusion between version numbers).
I also inteend to bring
up the system with BUILDMAPFLG and MAKEFILEREMAKEFLG both
defaulted to T, and alice can change them if she wants.
I have not done the changes to PRETTYDEF or to LOAD, nor
have i done some fixes to file packge so a
to interface LOADFNS correctly, and also handle the
problem of compiled and interpeted files a little better.
These should not be too difficult. The hard paatt
was the LOADFNS. I also plan to provide a LOADBLOCKS which
will load an entire block given any of its functions, and
to have the editor ask you if you want that where it
now asks you if you want the function loaded.
I would appreciate if you would get on the new loadup
LISPZ.SAV on NEWLISPat PARC< LISP.SAV on TEITELMAN at BBN,
and bang hell out of it. There are an incredible number
of different situation involving the scan stopping
in the middle of a defineq, after a compiled function,
coming back in asking for some VARS when you have
previously scanned all or some of the file, etc. etc.
I have exhaustively tested these as well as I can, but
would appreciate some hostile users.
I now have a loadup in which PRETTYPRINT also knows about
the filemap. I have a number more of things to do but here is
current situation:
When doing a MMAKEFILE REMAKE, either by specifying
it as an option or via MAKEFILEREMAKEFLG (which is now
initialized to T), PRETTYPRINT uses the filemap if
present. The map could have been built by a previous
LOADFNS, or by a previous MAKEFILE. (When BUILDMAPFLG
is T, PRETTYDEF builds a map for the new file independently
of whether it is remaking or not, and whether it has
a map for its source file or not). If the file is only
partly mapped, PRETTYDEF uses whatever of the map it can.
If there is no map, PRETTYDEF on remake option still goes
to the file to find the symbolics a la recompile.
The relative timings are given below:
(1) Time to to a MAKEFILE(PRETTY) without building a map
without using a map, without remaking
81.1 seconds 102 conses
(2) time to do a MAKEFILE(PRETTY) without using a map
or remaking, but with BUILDMAPFLG=T, i.e. so a map is being built.
82.8 seconds, 248 conses
This gives some idea of overhead for building the map (quite small in view of advantages).
(3) time to do a MAKEFILE(PRETTY REMAKE) without a map, i.e.
just getting symbolics off of file.
22.4 seconds
(4) time to do a MAKEFILE(PRETTY REMAKE) using a previous map
8.1 seconds (that's right!!!)
(5) by way of comparison, the time do do
a MAKEFILE(PRETTY FAST), i.e. not prettyprinting
is 19.7 seconds.
note thatthe time required goes up the more functions
that are changed. the above timings are with
no functions being changed. Obviusly, in the limit,
i.e. when every function in the file has been changed,
then the map, or remaking doesnt help at all.
However, note that you can do a makefile(PRETTY REMAKE),
either with or without a map, when all, some, or none
of the functions in pretty have been loaded.
if buildmapflg=T, a new map is built regardless.
The current loadup is on NEWLISP.SAV on <NEWLISP > PARC,
and on LISP.SAV in my directory at BBN.
Please bang on it.
I have tested it strenuously, but the trickiest parts
i think occur when there is only
a partial map, i.e. when you did a loadfns which
didnt have to search the whole file, and
when you have changed the FNS, i.e. added , deleted,
or switched orders on some of the functions
in the file. All of this is supposed to work, and
I have tested it all, but its kind of hairy.
Note: if you ever get screwed up, e.g. by typing control-
D and leaving a file open, oo the map gets out of synch
or something, yo can always do MAKEFILE(FILE NEW).
Note also, undoing the event thatbuilt the
map does not undo the map. I thought tha you might
want to do a loadfns, and then undo it in order
to make the functions you redefined come back, but
it seemed like you might as well rtain the results
of the mapping for maybe a later operation.
Note: everybody works ok if the name of the file is
obtained via error correction, i.e.
if you have errotypelst fixed up to check another dirctory,
or spelling correct or whatever, all works fine.
similarly, if you do LOADFNS(mumble FO$) everything
also works.
-------
14-APR-74 08:48:23,214
Date: 14 APR 1974 0848-PDT
From: WALKER
Subject: HELPSYS (OUTSIDE OF PARC)
- - - -
I talked breifly with Warren about your request. He wants to talk
with you about it in more detail.
-BOB
-------
14-APR-74 20:33:15,178
Date: 14-APR-74 2033
From: PRINTER
- - - -
File LMBARD.;2 sent to XGP
File LPT.1604543;1 sent to XGP
File PMLISP.;1 sent to XGP
File [NEWLISP]HIST.;1 sent to XGP
-------
14-APR-74 23:56:20,1403
Date: 14 APR 1974 2356-PDT
From: TEITELMAN
Subject: LOADFNS
cc: DEUTSCH, KAPLAN, BOBROW, GOODWIN at BBN, LEWIS at BBN,
cc: WOODS at BBN, BURTON at BBN, MOORE, BELL at BBN
- - - -
Another new loadup, this time the following new feautres:
(1) spellig correction in LOADFNS
(2) there is a function GETBLOCKDEC(FN FILE FLG),
which returns the block declaration thatcontains FN. If FLG=T,
returns only the function contained in the block.
(3) LOADFNS recognizes expression of the form (BLOCK . FNS),
and does a GETBLOCKDEC for each one.
(4) If the editor is called on a function which is not in core,
and the function is in a block,
the editor will ask if you also want the rest of
the block loaded (only loads those
function not already loaded)
(5) LOAD now builds a map when BUILDMAPFLG = T.
Here are some timings:
to load a small file in the old system, i.e. before load was changed
2365 conses 7.0 seconds
to load same file in new system with BUILDMAPFLG=NIL
2375 conses, 7.1 seconds
to load same file with BUILDMAPFLG=T
2439 conses 7.6 seconds
to makefile same file without the map, i.e. if loaded
with BUILDMAPFLG=NIL
148 conses, 5.7 seconds (note this is a REMAKE)
to makefile using the map
147 CONSES 2.0 SECONDS
I still have the following to do:
make recompile use the map, and interface loadfns with
file package.
WARREN
-------
15-APR-74 00:25:25,384
Date: 15 APR 1974 0025-PDT
From: TEITELMAN
Subject: NEW LISP
cc: LISP USERS
- - - -
There is a new lisp in operation. If you operate normally,
your makefiles will be 10 times as fast. However, i would
doulecheck my listings for the first couple of days,
and also save state with sysout. for details about what
is in the system, read <TEITELMAN>LOADFNS.TXT.
-------